1. Introduction
This project is an illustration of how Model-Driven Engineering tools and techniques can help in other model-based fields such as scientific activities (Agronomy in our case study).
1.1. People involved in this case study
-
Cédric Brun (from Obeo)
-
sd (as well as Florian Noyrit from CEA LIST)
1.2. Conventions
Here are some typographical conventions :
-
we denote modelsc a model in the sense of the scientific community
-
we denote modelmde a model in the sense of the [MDE] community
2. Expectations
-
In terms of modeling capabilities:
-
this is phase 1 of modeling (close to what GVLE does right now)
-
we want to write text and use graphical rendering to communicate
-
-
In terms of interoperability with other models:
-
DEVS is already a standard?
-
-
In terms of semantic/execution/simulation:
-
this is phase 2 (code generation) and 3 (exploration)
-
code generation can lead to XML outputs (.VPZ files that describe model structure + experience plans ?)
-
exploration/execution outputs values (intermediate)
-
http://devlog.cnrs.fr/idm2013 (Gauthier Quesnel presentation)
-
-
In terms of normative/standard support …
-
xxx to be completed by Hélène Raynal xxx
3. Description of the context
In this section we provide some element to understand the kind of modelssc that scientific entities such as INRA manipulate daily.
3.2. Screen captures
|
|
More can be found (in French) here. |
Pour la partie description hiérarchique, on utilise une approche systémique basée sur la connaissance du domaine (exemple on met ensemble les processus qui relèvent du bilan hydrique de la plante) et le niveau d’interaction. La profondeur de décomposition est fonction des attentes du modélisateur et des habitudes. On s’appuie aussi sur les propriétés DEVS (formalisme sous jacent).
4. Contributions
This section describe the modeling experiments.
THe basic documents (in addition to the one presented before) is the following : documents/ModèleExploitationAgricole.pdf
4.1. Approaches
There are several ways to tackle the problem.
We can follow [IDM12] metamodeling process:
We can also follow [MDSEP12]:
-
Modeling domain analysis
-
Modeling language design
-
Modeling language validation
Parler du papier de [Selic07] pour l’approche profil du CEA LIST. CF. cette figure.
4.2. DSL
4.3. Profile-based approach
Contribution by sd, Florian Noyrit, JMB.
4.3.1. What is a profile ?
-
Abstract syntax for a new language
-
Set of stereotypes
-
Set of OCL constraints
-
4.3.2. General process
The idea behing this approach is that there will be some benefits in the use of the UML™ standard. Hence the DSL will be based on UML™ by using the profile mechanisms.
As illustrated in this figure, here is the processus we can follow:
- Step #1
-
Starting from the expected DSL (most of the time a
modelscor a graphical représentation) and a description of the domain model (modelmde)
- Step #2
-
A domain modelmde is more precisely defined (e.g. a class diagram such as Main concepts of the domain model)
activities- Step #3
-
The concepts (e.g.,
Farmin Main concepts of the domain model) are mapped to the more suitable UML™ elements (e.g.,Classin Mapping concepts with UML metamodel to define a profile)
- Step #4
-
If the concepts directly match UML™ concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., Mapping concepts with UML metamodel to define a profile)
- Step #5
-
Else another solution (e.g., defining a metamodel from scratch) should be studied.
- Step #6
-
It is time then to "customize" the DSML to make it as close as possible as the user domain representation.
|
|
There are different ways of defining the domain model:
|
4.3.3. Iterative process
The above process is iterative. The constructs are introduced by step.
The profile is experimented in a modelsc importing the profile so that the user can validate
that the concepts are captured adequatly.
This is were the UML™ expert can use tuning possibilities.
4.3.4. Improvements
The next steps can consist in:
-
defining a dedicated diagram
-
providing a wizard for the new language
-
defining a specific property view ( and then right click on the generated property)
-
Working on the concrete syntax:
-
customizing the styles (look & feel)
-
customizing
-
customizing the Model explorer
-
packaging together the profile, the property view, the palette, etc.
-
|
|
|
4.3.5. Example of work on the concrete syntax
Let us illustrate the need for a specific concrete syntax.
Structural Domain Model
Functional Domain Model
Structural profile
Functional profile
Using the profile: Farm structure
Using the profile: Papyrus context
Crop Workshops description
Activity description (UML Activity Diagram)
Activity description (UML Activity Diagram)
Customizing the Model Explorer
Customizing the Palette (structure)
Customizing the Palette (activities)
Customizing the Palette (property view, structural element)
Customizing the Palette (property view activity element)
Animation and external tools coupling
4.4. Conclusion
4.4.1. Profile definition
-
in terms of stereotypes (extending metaclasses)
-
adding specific properties to the stereotype (e.g.,
periodin this figure) -
adding OCL constraints
4.4.2. Main differences
-
Using
ecore-
the process consists in starting from scratch, from an empty metamodel
-
the domain model is then define by construction
-
-
In the
UML profileapproach-
we start with an existing (complete) metamodel
-
and the profiling activity consist in restricting it to specific elements
-
the assumption is that their is a benefit in having both additional concepts and tooling, notably in terms of
-
extensibility mecanisms
-
scalability
-
-
4.4.3. (honest) Feedbacks
-
Easy tuning and customizing possibilities
-
Almost like doing regular UML modeling
-
UML good knowledge required
-
Not trivial
-
Great work from CEA (3.5 days of work)
-
Need close loop with the client (agile manifesto)
4.4.4. DSML from scratch: the "Wysiwyg approach"
-
No constraint on what we type
-
Immediate visualization of the result
-
Possibility to have templates
-
More and mode styles and quality
4.4.5. DSML as UML profiles: the "LaTeX approach"
-
Constrained language
-
No immediate visualisation of the result
-
Naturally based on templates
-
Rich in libraries and styles
-
Possibilities to see what you get on (almost) real-time
-
Collaborative and user-friendliness improvements
Frequently Asked Questions
What are the needs in terms of simulations/executions ?
(by Pascal Dayre): we need to explore complex agro-system dynamic. More information with Helene’s presentation http://devlog.cnrs.fr/idm2013 (vidéo, slides)
Why DEVS? And is it the only target language?
(by Pascal Dayre) DEVS n’est pas un langage cible mais un formalisme mathématique qui permet de modéliser les systèmes selon le paradigme événementiel discret. C’est le formalisme englobant qui permet de formaliser les intéractions entre les sous-composants d’un modèle et ceci de manière hiérarchique (sous-modèle de sous-modèle, etc…). DEVS est implémenté par le langage VLE. Les spous-comosants d’un modèle est lui implémenté avec d’autres approches formalisées ou mathémathique pour des systèmes qui ont un comportement "continu", équations au différence (c’est la démo lors de la visio), d’autres composants pourraient a priori avoir un comportement décrit par un réseau baysien, etc. Par contre, si on se trouve dans un cas discontinu, on retombe dans le formalisme DEVS pour redécouper en sous-comosant continu avec la déclaration des événements entre sous-composants (modèle atomique au sens DEVS). Donc, le langage VLE implémente ce formalisme DEVS en gérant un bus inter-composants. Il offre des passerelles vers d’autres logiciels R, etc… et permet de programmer ses propres comportements en langage C++.
Il offre donc un framework: je ne trouve pas dans la doc de description général de ce framework, ni la grammaire du langage. Peut-etre qu’Helene a une info, un contact. Par contre:
-
interface d’un modèle atomic (VLE-DEVS): http://www.vle-project.org/wiki/Atomic_model_development
-
modèle exécutable: http://www.vle-project.org/wiki/Executive_model_development
Le Langage cible est le langage VLE:
DEVS abbreviating Discrete Event System Specification is a modular and hierarchical formalism for modeling and analyzing general systems that can be discrete event systems which might be described by state transition tables, and continuous state systems which might be described by differential equations, and hybrid continuous state and discrete event systems. DEVS is a timed event system.
DEVS is a high level formalism that has the ability to encapsulate other formalisms. VLE allows you to use several formalisms in DEVS framework:
-
Ordinary Differential Equations: QSS based on quantization and DESS a wrapping of classical numerical schema like Runge-Kunta, by example.
-
Cellular automaton : CellDevs.
-
Difference equation: DifferenceEquation.
-
Petrinet : PetriNet.
-
Discrete and finite state automaton: Moore and Mealy machines, FDDevs and statechart : FSA.
-
Decision making: an extension of execution of activities plan based on conditional, temporal and precedents constraints.
Glossary
References and links
-
[DEVS] http://fr.wikipedia.org/wiki/Discrete_Event_System_Specification
-
[IDM12] Ingénierie Dirigée par les Modèles : des concepts a la pratique. Jean-Marc Jézéquel, Benoît Combemale, Didier Vojtisek. Ellipses 2012.
-
[Papyrus] https://www.eclipse.org/papyrus/
-
[RECORD] http://record.toulouse.inra.fr/
-
[Selic07] Selic, B. A systematic approach to domain-specific language design using UML. In Proceedings of the 10th IEEE International Symposium on Object and Component- Oriented Real-Time Distributed Computing (Washington, DC, USA, 2007), ISORC ’07, IEEE Computer Society, pp. 2–9.
-
[Tatibouet14] Jérémie Tatibouët. Approche Systématique basée sur fUML pour Formaliser la Sémantique d’Exécution des Profils UML. ThèseUniversité Paris Sud, octobre 2014.
-
[Tuto-Profile] A tutorial on designing and using UML profiles with Papyrus (2012-06-06)
About…
Photo credits: